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(54) Distributed data accessing technique 



(57) A distributed data accessing technique is dis- 
closed. The technique is realized by storing, at a first 
network station, information identifying data which is 
available at a second network station, the second net- 
workstation being different than the first network station. 
A signal is generated at the first network station repre- 
senting the information identifying the available data 



and linking information to the second network station.^ 
The signal is transmitted to a third network station, the 
third network station being different than the first and the 
second network stations. The transmitted linking infor- 
mation is operable at the third network station to estab- 
lish a network link over which the identified available da- 
ta is transmtttable from the second network station to 
the third network station. 
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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates generally to dis- 

««SUi i"Jr%+<-> • »/> rtsr* am^ iwhsvm m^rtim 1 1 ft ph I tiN O ri io _ 

LI IUUICU UCllGl llbLMVI IW C4IIU, I^UIIIVWIWIt;! i.^ u utw 

tributed data accessing technique. 

BACKGROUND OF THE INVENTION 

[0002] There are two prevalent models for electronic 
bill presentment that are currently used in industry. The 
first is an aggregation model 10, which is shown in Fig- 
ure 1 . In its simplest form, the aggregation model 1 0 in- 
cludes a customer 12, an aggregator 14, and a plurality 
of billers 16. The customer 12 can be, for example, an 
individual person, a family, or a business. The aggrega- 
tor 14 can be a financial institution (Fl) such as, for ex- 
ample, a bank. Alternatively, the aggregator 14 can be 
a separate entity which acts of behalf of a sponsor 18, 
which can also be an Fl such as a bank. Each biller 16 
can be of any billing institution type such as, for exam- 
ple, a local telephone company, a local electric compa- 
ny, a retail outlet, or a national long distance telephone 
company. 

[0003] Each biller 16 provides customer-related in- 
voice data to the aggregator 14. The aggregator 14 
serves as an intermediary between each biller 16 and 
the customer 12 by providing bill presentment directly 
to the customer 12. 

[0004] There are two variants of the aggregation mod- 
el 1 0 resulting from the ownership, or "branding", of the 
presentation experience and the communication chan- 
nel between the aggregator 14 and the customer 12. In 
one variant, the aggregator 14 may offer aggregator- 
branding, thus totally owning both the presentation ex- 
perience and the communication channel between the 
aggregator 14 and the customer 12. In the other variant, 
the aggregator 14 may offer sponsor-branding, thus 
staying "behind the scenes" in terms of the presentation 
experience and supporting the communication channel 
between the aggregator 14 and the customer 12. 
[0005] The second prevalent model for electronic bill 
presentment is a biller direct model 20, which is shown 
in Figure 2. In its simplest form, the biller direct model 
20 includes a customer 12 and at least one biller 16. In 
the biller direct model 20, each biller 16 retains the cus- 
tomer-related invoice data and the full relationship with 
the customer 12, i.e., the presentation experience and 
the communication channel. The customer 1 2 may have 
software for providing a capability similar to Web brows- 
er bookmarking so as to allow easy navigation between 
billers, and thus some level of virtual aggregation. How- 
ever, there is no actual aggregation such as with the ag- 
gregator 14 of the aggregation model 10 described 
above. 

[0006] The above-described models present a dichot- 
omy between a sponsor-centric view and a biller-centric 



view of bill presentment. That is, the aggregation model 
10 allows the aggregator 14 and/or the sponsor 18 to 
use customer-related invoice data, bill presentment, 
and the communication channel between the aggrega- 
s tor 1 4 and the customer 1 2 for cross-selling or other pe- 
nr\h/ara[ services The bIHsr dir9ct mode! 20 on the oth o r 
hand, insures that control of customer-related invoice 
data, bill presentment, and the communication channel 
between the biller 16 and the customer 12 remains with 
10 the biller 16. 

[0007] Also, neither of the above-described models 
adopt a truly customer-centric view. That is, neither of 
the above-described models allow a customer 12 to in- 
teract directly with individual billers 16 while retaining 
'5 the benefits of interacting with a single aggregator 14, 
such as the ability to retain a single authentication and 
log-in procedure and a common bill presentation frame- 
work. Further, neitherof the above-described models al- 
low a customer 12 to retain the benefits of interacting 
20 with a single aggregator 14 while allowing the aggrega- 
tor 14, billers 16, and sponsor 18 to retain certain pref- 
erences, such as the ability to retain control of customer- 
related data and a communication channel with each 
customer 12. Accordingly, it would be desirable to pro- 
25 vide a distributed data accessing technique which ad- 
dresses the above-mentioned shortcomings of the 
above-described models. 

OBJECTS OF THE INVENTION 

30 

[0008] One object of the present invention is to pro- 
vide a distributed data accessing technique that allows 
a customer to interact directly with individual billers while 
retaining the benefits of interacting with a single aggre- 
35 gator. 

[0009] Another object of the present invention is to 
provide a distributed data accessing technique that al- 
lows a customer to retain the benefits of interacting with 
a single aggregator while allowing the aggregator, bill- 
40 ers, and sponsor to retain control of customer-related 
data and a communication channel with each customer. 
[0010] Another object of the present invention is to 
provide a distributed data accessing technique that al- 
lows complete flexibility as to who is offering bill present- 
45 ment: billers only, aggregator only, or some combination 
of the above. 

[0011] Another object of the present invention is to 
provide a distributed data accessing technique that sup- 
ports an audit trail which can serve any of a variety of 
50 purposes, including improved customer care. 

[001 2] The above-stated objects, as well as other ob- 
jects, features, and advantages, of the present invention 
will become readily apparent from the following detailed 
description which is to be read in conjunction with the 
55 appended drawings. 
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SUMMARY OF THE INVENTION 

[0013] According to the present invention, a distribut- 
ed data accessing technique is realized by storing, at a 
first network station, information identifying data which 
is available at a second network station. The first net- 
work station can be, for example, an electronic payment 
and customer service entity. The second network station 
can be, for example, a billing entity such as a utility com- 
pany. The information identifying the data that is avail- 
able at the second network station can be, for example, 
information which indicates that a bill is available at the 
second network station. 

[0014] A signal is generated at the first network sta- 
tion. The signal represents the information identifying 
the available data at, and linking information to, the sec- 
ond network station. The linking information can be, for 
example, a web site address along with some additional 
parameters. 

[001 5] The signal is transmitted to a third network sta- 
tion. The third network station can be, for example, a 
user entity such as a personal computer. The transmit- 
ted linking information is operable at the third network 
station to establish a network link over which the iden- 
tified available data is transmittable from the second net- 
work station to the third network station. That is, the third 
network station can invoke the linking information so as 
to create, for example, a link to the web site of a billing 
entity. 

[0016] The signal is typically generated in response 
to a request for data. Such a request can include an 
identification of a user so that the user can be authenti- 
cated. The signal is then generated after the user is au- 
thenticated. The request is typically received from the 
third network station. The request, as well as any other 
events that occur between the various network stations, 
can be logged at the first network station. The logged 
events can then be accessed by another entity, such as, 
a centralized customer service center, which could be a 
fourth network station. 

[0017] The identified available data is typically stored 
at the second network station. This data could, if de- 
sired, be provided to the second network station by an 
entity located outside of the network, such as a legacy 
billing system or an established billing aggregator. 
[0018] According to other aspects of the invention, the 
first network station receives a notification that the iden- 
tified available data was transmitted from the second 
network station to the third network station. The identi- 
fied available data is preferably transmitted from the 
second network station directly to the third network sta- 
tion over the network link established between the sec- 
ond and third network stations as discussed above. The 
identified available data can then be transmitted from 
the second network station to the third network station 
so as to be displayed in a presentation format. The pres- 
entation format can be, for example, an internet web 
page or a frame of an internet web page. 



[0019] Preferably, only a single authentication proce- 
dure is required for a user entity to receive available data 
identifying information and linking information for differ- 
ent data available a different sites, e.g. different bills at 
s different biller sites. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0020] In order to facilitate a fuller understanding of 
10 the present invention, reference is now made to the ap- 
pended drawings. These drawings should not be con- 
strued as limiting the present invention, but are intended 
to be exemplary only. 

[0021 ] Figure 1 is an aggregation model for electronic 
15 bill presentment. 

[0022] Figure 2 is a biller direct model for electronic 
bill presentment. 

[0023] Figure 3 is an infrastructure diagram of a dis- 
tributed database entity in accordance with the present 
20 invention. 

[0024] Figure 4 is a schematic diagram of an electron- 
ic bill presentment and payment system in accordance 
with the present invention, 

[0025] Figure 5 is a schematic diagram of an electron- 
's ic payment and customer service (EPCS) entity in ac- 
cordance with the present invention. 
[0026] Figure 6 is a schematic diagram of the elec- 
tronic bill presentment and payment system shown in 
Figure 4, extended to include certain associated directly 
30 related systems. 

[0027] Figure 7 is a schematic diagram of the elec- 
tronic bill presentment and payment system shown in 
Figure 4, extended to include certain associated indi- 
rectly related systems. 
35 [0028] Figure 8 is a schematic diagram of the elec- 
tronic bill presentment and payment system shown in 
Figure 4, extended to include certain associated cus- 
tomer care entities. 

[0029] Figure 9 is a schematic diagram of the elec- 
40 tronic bill presentment and payment system shown in 
Figure 4, extended to include a centralized customer 
care entity. 

[0030] Figure 10 is a flowchart diagram showing initial 
sign-on data and message flows between a user entity 

45 and a banking entity in the electronic bill presentment 
and payment system shown in Figure 4. 
[0031 ] Figure 1 1 is a flowchart diagram showing sign- 
on and authentication data and message flows between 
a user entity, a banking entity, and an EPCS entity in the 

so electronic bill presentment and payment system shown 
in Figure 4. 

[0032] Figure 12 is a flowchart diagram showing bill 
availability data and message flows between a user en- 
tity, a banking entity, and an EPCS entity in the electron- 
55 ic bill presentment and payment system shown in Figure 
4. 

[0033] Figure 1 3A is a flowchart diagram showing bill- 
ing entity presentment data and message flows be- 
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tween a user entity, a billing entity, and an EPCS entity 
in the electronic bill presentment and payment system 
shown in Figure 4. 

[0034] Figure 1 3B is a flowchart diagram showing bill- 
ing aggregator bill presentment data and message flows 
between a user entity, a billing entity, an EPCS entity, 
and an established billing aggregator in the electronic 
bill presentment and payment system shown in Figure 4. 
[0035] Figure 1 3C is a flowchart diagram showing al- 
ternative system bill presentment data and message 
flows between a user entity, an EPCS entity, and an al- 
ternative bill presentment and payment system in the 
electronic bill presentment and payment system shown 
in Figure 4. 

[0036] Figure 14 is a flowchart diagram showing bill 
payment data and message flows between a user entity, 
an EPCS entity, and a billing entity in the electronic bill 
presentment and payment system shown in Figure 4. 
[0037] Figure 15 is a flowchart diagram showing bill 
remittance and debiting data and message flows be- 
tween an EPCS entity and a billing entity and a banking 
entity in the electronic bill presentment and payment 
system shown in Figure 4. 

[0038] Figure 1 6 shows an example of a branded in- 
terface having a sign -on request prompt that includes a 
username field and a password field. 
[0039] Figure 1 7 shows an example of a banking en- 
tity home page, including a "view bills" icon, a "view 
checking account" icon, and a "view savings account" 
icon. 

[0040] Figure 1 8 shows a first modified banking entity 
home page having a frame presenting new bill availa- 
bility data. 

[0041] Figure 19 shows a second modified banking 
entity home page having a frame presenting detailed bill 
data. 

[0042] Figure 20 is a flowchart diagram showing cus- 
tomer service data and message flows between a cen- 
tralized customer service center, and an EPCS entity, a 
billing entity, and a banking entity in the electronic bill 
presentment and payment system shown in Figure 4. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

[0043] Referring to Figure 3, there is shown an infra- 
structure diagram of a distributed database entity 30 in 
accordance with the present invention. The distributed 
database entity 30 comprises a database component 32 
and a plurality of message interfaces 34-40 for facilitat- 
ing communication between the database component 
32 and other distributed database entities and system 
components. The database component 32 typically con- 
tains data that is controlled or "owned" by the controller 
or "owner" of the distributed database entity 30. For ex- 
ample, if the distributed database entity 30 is owned by 
a financial institution (Fl) such as a bank, then the da- 
tabase component 32 could contain information such as 



checking and savings account balances. It should be 
noted, however, that the database component 32 can 
also contain data from other distributed database enti- 
ties and system components, as will be described in de- 
s tail below. 

Tt\(\AA1 Th<a nhiralitw r\f moccano intorfpriOQ 34-40 in- 

eludes an internal message interface 34, an external 
message interface 36, a partner message interface 38, 
and a customer care message interface 40. 

10 [0045] The internal message interface 34 defines 
messages that are used to communicate and query data 
between the distributed database entity 30 and other 
distributed database entities, or other system compo- 
nents having an internal message interface. For exam- 

*5 pie, in a bill presentment and payment- system, com- 
munication between a banking entity and a billing entity 
may be required. 

[0046] The external message interface 36 defines 
messages that are used to communicate and query data 
20 between the given distributed database entity 30 and 
any existing system(s) that are directly related to the dis- 
tributed database entity 30. For example, an Fl such as 
a bank can have an existing direct deposit account 
(DDA) system. 

25 [0047] The partner message interface 38 defines 
messages that are used to communicate and query data 
between the distributed database entity 30 and any ex- 
isting system(s) that are indirectly related to the given 
distributed database entity 30, For example, in a bill pre- 

30 sentment and payment system, communication with an 
established billing aggregator may be necessary to sat- 
isfy customer demands. 

[0048] The customer care message interface 40 de- 
fines messages that are used to communicate and que- 

35 ry data between the given distributed database entity 30 
and a customer care entity. For example, in a bill pre- 
sentment and payment system, a billing entity may allow 
a third party to access bill data in order to provide feed- 
back to bill customers. 

40 [0049] It should be noted that all of the above-de- 
scribed interfaces will be described in greater detail be- 
low. 

[0050] Referring to Figure 4, there is shown a sche- 
matic diagram of a versatile electronic bill presentment 

45 and payment system 50 in accordance with the present 
invention. The system 50 includes a user entity 52, a 
banking entity 54, a billing entity 56, and an electronic 
payment and customer service (EPCS) entity 58. For 
purposes of this detailed description, each of entities 52, 

so 54, 56 and 58 is similar to the distributed database entity 
30, as described above, but could, if desired, have only 
an internal message interface 34 so that communica- 
tions can take place between each entity. 
[0051] It should be noted that, although only a single 

55 user entity 52, banking entity 54, billing entity 56, and 
EPCS entity 58 are shown in the system 50, a plurality 
of each of these entities may exist in an actual versatile 
electronic bill presentment and payment system in ac- 



7 



EP1 136 924 A1 



8 



cordance with the present invention. Since the entities 
52, 54, 56 and 58 are all distributed database entities, 
they all communicate through internal message inter- 
faces 34. These communications are performed over in- 
terconnections 60, which can be wire, optical fiber, or 
wireless interconnections. 

[0052] Each internal message interface 34, external 
message interface 36, partner message interface 38, 
and customer care message interface 40, can be imple- 
mented using any number of existing message-based 
communication systems such as, for example, a TCP/ 
IP message-based communication system running on 
the infrastructure of the internet. Alternatively, the inter- 
faces 34, 36, 38 and 40 could be implemented using 
proprietary messaging software on a private network or 
intranet. It should also be noted that there are no re- 
quirements as to the nature of the messaging protocol, 
or any middleware used to support the messaging. 

THE USER ENTITY 

[0053] The user entity 52 is typically a personal com- 
puter (PC) that is directly connected to the system 50, 
or is connected to the system 50 through a network serv- 
er (not shown). Thus, the database component 32 as- 
sociated with the user entity 52 can be located on the 
PC, e.g., a traditional "fat" client, or on the network serv- 
er, e.g., an HTML browser client. It should be noted that 
the database component 32 associated with the user 
entity 52 could, if desired, also be located in one or dis- 
tributed among all of the other distributed database en- 
tities, which can download data to the user entity 52, e. 
g., a Java client. Thus, each database component 32 
should not be thought of as a single, monolithic data- 
base. Rather, each database component 32 is better de- 
scribed as a distributed repository of data categorized 
by the entity that "owns" the data. 
[0054] Wherever it is located, the database compo- 
nent 32 associated with the user entity 52 stores data 
that is related to the type of user interface (Ul) that is 
being presented to a subscriber of the system 50. For 
example, the database component 32 associated with 
the user entity 52 can store data that is related to the 
particular type of presentation technology being used, 
e.g., a "fat" client, an HTML browser client, or a Java 
client, a specific application, or a particular version of an 
application. The database component 32 associated 
with the user entity 52 can also store data that is related 
to a particular computing session, such as the existence 
of a computing session and/or the duration of a comput- 
ing session, and subscriber authentication data, which 
is described in detail below. 

[0055] The main function of the user entity 52 is to 
build a U I using data obtained from the other distributed 
database entities, and then present the U I to a subscrib- 
er of the system 50. The presentation of the Ul to a sub- 
scriber Is dependent upon the particular type of presen- 
tation technology being used, e.g., a "fat" client, an 



HTML browser client, or a Java client. For example, a 
Ul for a Java client requires that presentation data be 
downloaded from one of the other distributed database 
entities. 

s [0056] Other functions of the user entity 52 include 
storing certain data locally so as to facilitate off-line ed- 
iting and viewing, maintaining a state in a connection- 
less environment, e.g., an HTTP environment, and 
sensing the availability of software updates and manag- 

10 jng their subsequent application. All of these functions 
depend on the nature of the client, e.g., a "fat" client, an 
HTML browser client, or a Java client. Another function 
of the user entity 52 is storing subscriber authentication 
data, e.g., a security ticket that is used to gain access 

*5 to other distributed database entities in the system 50. 

THE BANKING ENTITY 

[0057] The banking entity 54, which is typically an FI, 
20 such as a bank, is generally viewed as a primary point 
of contact for a subscriber to the system 50, typically 
providing an appearance of aggregation to the subscrib- 
er. This is primarily due to the trust that consumers typ- 
ically place in a bank brand, and the fact that bank cus- 
25 tomers who already bank online are also likely to want 
to receive bills online. Thus, in the following discussion, 
the banking entity 54 is assumed to be the aggregator 
of the system 50. 

[0058] It should be noted, however, that any one of 

30 the other entities could also be the aggregator of the 
system 50 in accordance with the present invention. 
There are several factors which can be used to deter- 
mine aggregator status such as market clout. 
[0059] The banking entity 54 typically gains access to 

35 the system 50 through a network server (not shown). 
Thus, the database component 32 associated with the 
banking entity 54 can be located in the network server, 
but could also be located in a system associated with 
the banking entity 54, such as a DDA system. Such a 

40 DDA system could be accessed through the external 
message interface 36 of the banking entity 54, as de- 
scribed in detail below. The database component 32 as- 
sociated with the banking entity 54 could, if desired, also 
be located in one, or be distributed among all, of the 

45 other distributed database entities. 

[0060] Wherever it is located, the database compo- 
nent 32 associated with the banking entity 54 stores 
bank-specific subscriber profile data profile such as, for 
example, subscriber names and addresses and sub- 

50 scriber account numbers. The database component 32 
can also store account information, such as static ac- 
count information, e.g., lease rate, principle, and dy- 
namic account information, e.g., balance, and profile da- 
ta specifically associated with the FI, such as graphics, 

55 business rules, banking-related transaction histories, 
and aggregation relationships, e.g. those between the 
FI and billers. 

[0061 ] Since it is likely that the system 50 wili be used 
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with existing banking systems, such as an existing DDA 
system, one of the main functions of the banking entity 
54 is the continuation of current banking and bill pay- 
ment functionality, including maintaining customer pro- 
files and already existing interfaces. In its role as aggre- 
gator, the banking entity 54 also provides data to the 
user entity 52 to be used for the creation of a navigation 
portion of a Ul. For an HTML browser client, this data 
would be used to create a navigation frame, but not a 
content specific frame. The banking entity 54 can also 
provide data to the user entity 52 to be used for the cre- 
ation of a Ul for traditional banking and bill payment. 
[0062] Since the banking entity 54 is generally viewed 
as the primary point of contact for a subscriber to the 
system 50, the banking entity 54 also functions as the 
likely, but not exclusive, entry point for subscriber sign- 
on. Thus, the banking entity 54 typically controls the 
sign-on and authentication procedures for subscribers 
using the user entity 52. It should be noted that the bank- 
ing entity 54 typically works in conjunction with the 
EPCS entity 58 in controlling the authentication proce- 
dure, as described in detail below. 
[0063] Another function of the banking entity 54 in- 
cludes tracking bank related events and storing them in 
an event tracking database, which is typically associat- 
ed with the EPCS entity 58, as will also be described in 
detail below. 

THE BILLING ENTITY 

[0064] The billing entity 56 is commonly a biller such 
as, for example, a utility company. The billing entity 56 
typically gains access to the system 50 through a net- 
work server (not shown). Thus, the database compo- 
nent 32 associated with the billing entity 56 can be lo- 
cated in the network server. However, if desired, the da- 
tabase component could also be located in a system as- 
sociated with the billing entity 56, such as a legacy billing 
system, or in one or among all of the other distributed 
database entities. Such a legacy billing system could be 
accessed through the external message interface 36 of 
the billing entity 56, as described in detail below. 
[0065] Wherever it is located, the database compo- 
nent 32 associated with the billing entity 56 stores biller- 
specific subscriber profile data, such as subscriber 
names and addresses and subscriber account numbers 
and types, e.g., business vs. residential phone line. The 
database component 32 also stores billing data for use 
by the user entity 52 in building the Ul for the subscriber. 
The billing data can include bill availability data, detailed 
billing data, ads and other cross-sale displays and links, 
and bill payment terms and conditions. 
[0066] The database component 32 associated with 
the billing entity 56 can also store biller transaction his- 
tory, such as bill data manipulation, e.g., viewing, 
searching, and sorting, as well as cross-sell events. The 
database component 32 can further store biller profile 
data, such as graphics, business rules, and relation- 



ships with aggregators such as banks. 
[0067] The main function of the billing entity 56 is to 
provide billing data to the user entity 52 for use in cre- 
ating the Ul for the subscriber. The billing entity 56 also 

5 provides bill availability data to an aggregator database, 
whether it is located in the banking entity 54, the EPCS 
entity 58, or another entity, for use in providing notice of 
bill availability to subscribers. The billing entity 56 can 
also access legacy billing systems through the external 

10 message interface 36 of the billing entity 56, as indicated 
above. 

[0068] Another function of the billing entity56 is track- 
ing biller-related events and storing them in an event 
tracking database, which is typically associated with the 
is EPCS entity 58, as described in detail below. 

THE EPCS ENTITY 

[0069] The EPCS entity 58 can generally be de- 
20 scribed in terms of a data processing system 70, such 
as shown in Figure 5. The data processing system 70 
preferably includes at least one processor (P) 72, mem- 
ory (M) 74, and input/output (I/O) interface 76, which are 
connected to each other by a bus 78, for implementing 
25 the functions of the EPCS entity 58, as described in de- 
tail below. 

[0070] Referring again to Figure 4, the EPCS entity 
58 typically gains access to the system 50 through a net- 
work server (not shown). Thus, the database compo- 
30 nent 32 associated with the EPCS entity 58 can be lo- 
cated in the network server. However, if desired, the da- 
tabase component 32 associated with the EPCS entity 
58 can also be located in a system associated with the 
EPCS entity 58, such as a legacy aggregating system, 
35 or in one or among al! of the other distributed database 
entities. Such a legacy aggregating system could be ac- 
cessed through the external message interface 36 of the 
EPCS entity 58, as described in detail below. 
[0071] Wherever it is located, the database compo- 
40 nent 32 associated with the EPCS entity 58 stores bill 
payment-specific subscriber profile data, such as sub- 
scriber names and addresses, subscriber DDA account 
numbers, and subscriber credit ratings. The database 
component 32 also stores bill payment warehouse data, 
45 such as user-specific payees, single occurrence pay- 
ments, and recurring payments/models. 
[0072] As previously described, both the banking en- 
tity 54 and the billing entity 56 track and store events in 
an event tracking database. This event tracking data- 
so base is typically located in the database component 32 
associated with the EPCS entity 58, and typically in- 
cludes event summaries and links to other databases, 
perhaps residing at other entities, which provide event 
details and/or an audit trail. 
55 [0073] The database component 32 associated with 
the EPCS entity 58 also stores bill payment transaction 
histories, and system subscriber profile data, such as 
metadata about subscribers and metadata about sub- 
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scribers' relationships to other entities, e.g., a list of bill- 
ers that a subscriber has enabled. The database com- 
ponent 32 further stores billing-related profile informa- 
tion on the system aggregator and billers, such as meta- 
data about billing arrangements, e.g., flat rate, per sub- 
scriber, event-driven, etc., and aggregation data, such 
as new bill availability and messages or special an- 
nouncements available from the billing entity 56. The 
database component 32 associated with the EPCS en- 
tity 58 may additionally store security data, such as re- 
quired sign-on information and macro-level authoriza- 
tions, and customer service data, such as frequently 
asked questions (FAQ's), Fl and biller contact informa- 
tion, and problem resolution data. 
[0074] The EPCS entity 58 is the entity which ties the 
distributed database entities together. The EPCS entity 
58 accomplishes this by functioning as an integration 
agent which maintains bill payment profiles and ware- 
house data, aggregates bill availability and status data, 
but not bill content or presentation, and maintains an 
event tracking database, i.e. an audit trail, that can be 
accessed by all of the database entities. Also, in order 
to facilitate a single point of sign-on, the EPCS entity 58 
functions as the authentication gate keeper. This is not 
intended to imply that the EPCS entity 58 necessarily 
maintains user identification numbers and/or pass- 
words. However, it does mean that the EPCS entity 58 
accepts sign -on requests and doles out authentication 
"tickets" in response thereto, in conjunction with the 
banking entity as described above. 
[0075] Like user identification numbers and pass- 
words, other data elements, such as event details, may 
be aggregated at the EPCS entity 58, but may still phys- 
ically reside in a distributed manner across several of 
the database entities. The EPCS entity 58 may also 
route e-mail messages to and from the various database 
entities, as well as store e-mail messages sent to and 
from the various database entities. 

INTERNAL MESSAGE PROCESSING 

[0076] The following types of messages are examples 
of messages which may be employed to implement an 
internal message interface 34 in accordance with the 
present invention. The message specification or file for- 
mat can be either standard, i.e., open, or special, i.e. 
proprietary. 

USER ENTITY INTERNAL MESSAGE PROCESSING 

[0077] Depending upon the nature of the presentation 
technology being used, e.g., a "fat" client, an HTML 
browser client, or a Java client, the user entity 52 may 
need to process an internal message to store a security 
ticket for later use in gaining access to other distributed 
database entities in the system 50, and/or to update any 
resident software. The user entity 52 may also need to 
process an internal message containing various types 



of information (assuming a push model), and/or internal 
e-mail messages, such as those for receiving data from 
other database entities. 

5 BANKING ENTITY, INTERNAL MESSAGE 
PROCESSING 

[0078] The banking entity 54 will process an internal 
message to add/update/delete/retrieve F I branding in- 
fo formation, and to add/update/delete an entry from a list 
of billers that have been aggregated. The banking entity 
54 will also process an internal message to activate a 
subscriber for home banking via a messaging protocol, 
which can be an existing messaging protocol, such as 
15 OFX, or a batch process, and to query/update bank sub- 
scriber profile data for purposes of customer care. The 
banking entity 54 will further process an internal mes- 
sage to query bank transaction history for customer care 
and for linking to the event tracking database, and to 
20 retrieve a list of billers available under the Fl sponsor 
umbrella or to place the list of billers available under the 
Fl sponsor umbrella in an aggregation database. Plac- 
ing the list of billers available under the Fl sponsor um- 
brella allows the EPCS entity 58 to tailor the list by Fl 
25 sponsor. 

[0079] The banking entity 54 will additionally process 
internal e-mail messages such as those for sending data 
to other database entities, receiving data from other da- 
tabase entities, and broadcasting data to other data- 
30 base entities. 

BILLING ENTITY INTERNAL MESSAGE 
PROCESSING 

35 [0080] The billing entity 56 will process an internal 
message to add/update/delete/retrieve biller branding 
information, and to activate a subscriber for electronic 
bill presentment via a messaging protocol, which can be 
an existing messaging protocol, for example OFX, or a 

40 batch process. The billing entity 56 will also process an 
internal message to retrieve bill availability data, retrieve 
bill detail data, and retrieve bill presentation specifica- 
tions or content. The retrieved data could, for example, 
be URL links to ads and notices, HTML data, or OFX 

45 data. 

[0081] The billing entity 56 will also process an inter- 
nal message to query/update biller subscriber profile da- 
ta for purposes of customer care, and to query biller 
transaction history for customer care and for linking to 
so the event tracking database. The billing entity 56 will ad- 
ditionally process internal e-mail messages, such as 
those for sending data to other database entities, receiv- 
ing data from other database entities, and broadcasting 
data to other database entities. 

55 

EPCS INTERNAL MESSAGE PROCESSING 

[0082] The EPCS entity 58 will process internal event 
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tracking messages used to gain access to two types of 
information in the event tracking database: summary 
data and a link to another database entry that can pro- 
vide more detail, such as subscriber enrollment data, 
subscriber service activation data, e.g., biller, bill pay- 
merit, banking, etc., sign -on data, bi" availability data : 
bill viewed data, bill payment generated data which is 
optionally associated with presented bill data, subse- 
quent bill payment events data, e.g., submitted, proc- 
essed, failed, cleared, remittance received by biller, etc., 
cross-sell events data, e.g., ad/offer viewed, ad/offer 
clicked, product/service purchased, terms & conditions 
viewed data, and e-mail created/read/deleted data. 
[0083] The EPCS entity 58 will also process internal 
messages related to subscriber profile data, such as to 
add/modify/delete/read subscriber profile data, often as 
a function of the events listed above, e.g., enrollment, 
activation, etc. 

[0084] The EPCS entity 58 will additionally process 
internal security messages. Such internal security mes- 
sages may relate to authentication, which result in the 
EPCS entity 58 issuing a security ticket. It should be not- 
ed that an authentication request does not have to be 
received as a result of a subscriber directly contacting 
the banking entity 54, but may be. initiated if a subscriber 
attempts to gain access to the billing entity 56, without 
contacting the banking entity 54. The point being that 
with a security ticket a subscriber is generally allowed 
to freely traverse any database entity in the system 50 
without going through repeated sign-on procedures. 
[0085] An internal security message may relate to 
macro-level authorization, resulting in issuance of a se- 
curity ticket that includes credentials allowing a sub- 
scriber access to a particular billing entity, without ad- 
dressing micro-level authorization issues such as the 
operations the subscriber will be allowed to perform. 
[0086] An internal security message may also result 
in issuance of a security ticket without authentication. 
Such a message will originate from a trusted party, e.g., 
an Fl performing its own authentication. 
[0087] It should be noted that the use of a security 
ticket enables, but does not mandate, a single sign-on 
procedure. In other words, a database entity, such as 
the billing entity 56, may, for whatever reason, require 
additional authentication information. 
[0088] The EPCS entity 58 will further process inter- 
nal messages relating to aggregation data. For exam- 
ple, an EPCS entity 58 will process an internal message 
to create a link to summary or detailed bill information, 
or to create a link to message, notice, ad, or some other 
kind of non-bill information that is available from the bill- 
ing entity 56, 

[0089] Furthermore, the EPCS entity 58 will process 
an internal message to query/update bill payment trans- 
action history for purposes of customer care. The EPCS 
entity 58 will process internal e-mail messages, such as 
those associated with routing e-mail, picking-up e-mail, 
and querying an e-mail mailbox. The EPCS entity 58 
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may also process internal messages related to data 
mining. Such messages are handled very carefully to 
ensure privacy, perhaps even providing an ACL or other 
mechanisms to ensure privacy. The results of such mes- 
s sages may be delivered out of band, e.g., by batch. 

EXTERNAL MESSAGE PROCESSING 

[0090] Referring to Figure 6, there is shown a sche- 
10 matic diagram of the versatile electronic bill present- 
ment and payment system 50, along with certain asso- 
ciated directly related systems. The directly related sys- 
tems includes a desktop database 80, a DDA system 
82, a legacy billing system 84, and a legacy remittance 
'5 system 86. The communications between the various 
database entities and their associated directly related 
systems are performed over interconnections 88, which 
can be wire, optical fiber, or wireless based interconnec- 
tions. The message specification or file format can be 
20 either standard, i.e., open, or special, i.e. proprietary. 

USER ENTITY, EXTERNAL MESSAGE PROCESSING 

[0091] Depending upon the nature of the presentation 
25 technology being used, e.g., a "fat" client, an HTML 
browser client, or a Java client, the user entity 52 may 
need to process an external message in order to com- 
municate with a related system, such as the desktop da- 
tabase 80. To support a system, it may be necessary to 
30 implementthe external message interface 36 of the user 
entity 52 using an existing, and possibly extended, pro- 
tocol specification, such as Gold, NPC, or OFX, as will 
be understood by those skilled in the art. 

35 BANKING ENTITY EXTERNAL MESSAGE 
PROCESSING 

[0092] The banking entity 54 will process external 
messages to and from a related system, such as the 

40 DDA system 82, in order to query and update informa- 
tion, for example subscriber profile data, subscriber ac- 
count data, out-of-band (e.g., ATM) account activity and 
statement history. It may also be desirable for the bank- 
ing entity 54 to interface with other banking systems (e. 

45 g. ( stops). 

BILLING ENTITY EXTERNAL MESSAGE 
PROCESSING 

so [0093] The billing entity 56 will process external mes- 
sages to and from related systems, such as the legacy 
billing system 84, in order to query and update informa- 
tion, for example subscriber profile data, subscriber ac- 
count data, account activity and statement history. Most 

55 of this data is industry, if not biller, specific. 
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EPCS EXTERNAL MESSAGE PROCESSING 

[0094] The EPCS entity 58 will process external mes- 
sages to and from related systems, such as the legacy 
remittance system 86. The legacy remittance system 86 
could, for example, be an ACH, RPP, RPS, or Direct 
Send, as will be well understood by those skilled in the 
art. 

PARTNER MESSAGE PROCESSING 

[0095] Referring to Figure 7, there is shown a sche- 
matic diagram of the versatile electronic bill present- 
ment and payment system 50, along with some associ- 
ated indirectly related systems. The indirectly related 
systems includes a personal finance system 90, a bank- 
ing system 92, an established billing aggregator 94, and 
an alternative bill presentment and payment system 96. 
The communications between the various database en- 
tities and the indirectly related systems are performed 
over interconnections 98, which can be wire, optical fib- 
er, or wireless interconnections. The message specifi- 
cation or file format can be either standard, i.e., open, 
or special, i.e. proprietary. 

USER ENTITY PARTNER MESSAGE PROCESSING 

[0096] Depending upon the nature of the presentation 
technology being used, e.g., a "far client, an HTML 
browser client, or a Java client, the user entity 52 may 
need to process a partner message in order to commu- 
nicate with a partner, such as the personal finance sys- 
tem 90. The personal finance system 90 could, for ex- 
ample, be a personal financial manager (PFM) software 
package such as Quicken (TM) or Money (TM). 

BANKING ENTITY PARTNER MESSAGE 
PROCESSING 

[0097] The banking entity 54 will process partner 
messages to and from a partner, such as the banking 
system 92. 

BILLING ENTITY PARTNER MESSAGE 
PROCESSING 

[0098] The billing entity 56 will process partner mes- 
sages to and from a partner, such as the established 
billing aggregator 94. Such a partner relationship may 
be required if a large group of subscribers are using the 
established billing aggregator 94, and thereby have the 
leverage to demand that all of their bills be communicat- 
ed through the established billing aggregator 94. 
[0099] The established billing aggregator 94 is essen- 
tially treated as a proxy for the billers that it represents. 
Thus, subscribers to the system 50 through the estab- 
lished billing aggregator 94 are treated in the same man- 
ner as direct subscribers to the system 50. This means 



that subscribers to the established billing aggregator 94 
will receive the same event tracking, customer service, 
and payment processing functionality as direct sub- 
scribers to system 50. 

s [01 00] To present a bill generated by the established 
billing aggregator 94 the system 50 may, for example, 
receive bill availability data and the URL of a web server 
of the established billing aggregator 94. The billing entity 
56 stores detailed bill data on the web server of the es- 

10 tablished billing aggregator 94 so that subscribers may 
obtain an HTML presentation of detailed bill data from 
the aggregator bill server. In this scenario, the partner 
message interface 38 would be essentially the same as 
an internal message interface 34, but could, if desired, 

is have added bulk transfer capability. 

EPCS PARTNER MESSAGE PROCESSING 

[0101] The EPCS entity 58 will process partner mes- 
sages to and from a partner, such as the alternative bill 
presentment and payment system 96. Such a partner 
relationship may be required if a billing entity 56 has a 
subscriber base that includes both subscribers to the 
system 50 and subscribers to the alternative bill present- 
ment and payment system 96. 
[0102] In such a case, the system 50 could function 
as a billing aggregator for the alternative bill present- 
ment and payment system 96, or vice-versa. The alter- 
native bill presentment and payment system 96 and its 
subscribers might not receive any of the benefits of the 
messaging functionality provided by the present system 
50. Only limited functionality might be provided. That is, 
the partner message interface 38 might only provide the 
functionally required to present bills through the alter- 
native bill presentment and payment system 96. As will 
be recognized by those skilled in the art, the EPCS entity 
58 will typically require capabilities of a billing entity 56 
in order to present bills to and from the alternative bill 
presentment and payment system 96. 

CUSTOMER CARE MESSAGE PROCESSING 

[0103] Referring to Figure 8, there is shown a sche- 
matic diagram of the versatile electronic bill present- 
ment and payment system 50, along with certain asso- 
ciated customer care entities. The customer care enti- 
ties include a user entity self service center 1 00, a bank- 
ing entity customer service center 102, a billing entity 
customer service center 104, and an EPCS customer 
service center 106. The communications between the 
various database entities and their associated customer 
care entities are performed over interconnections 108, 
which can be wire, optical fiber, or wireless interconnec- 
tions. The message specification or file format can be 
either standard, i.e., open, or special, i.e. proprietary. 
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USER ENTITY CUSTOMER CARE MESSAGE 
PROCESSING 

[01 04] Depending upon the nature of the presentation 
technology being used, e.g., a "fat" client, an HTML 
browser Client, or a Java client, the user entity 52 rn«y 
need to process a customer care message in order to 
communicate with a customer care entity, such as the 
user entity self service center 100. The user entity self 
service center 1 00 could, for example, be a self service 
diagnostic tool. 

BANKING ENTITY CUSTOMER CARE MESSAGE 
PROCESSING 

[0105] The banking entity 54 will process customer 
care messages from a customer care entity, such as the 
banking entity customer service center 102. A customer 
care message may be a request for data or a request to 
modify existing data. Such customercare messages are 
processed by providing the requested data or providing 
a confirmation that the existing data has been modified 
to the banking entity customer service center 102. The 
banking entity customer service center 102 could, for 
example, be a third party telemarketing group that is al- 
lowed access to banking and overall system data in or- 
der to provide feedback to system subscribers. 

BILLING ENTITY CUSTOMER CARE MESSAGE 
PROCESSING 

[01 06] The billing entity 56 will process customer care 
messages from a customer care entity, such as the bill- 
ing entity customer service center 1 04. A customer care 
message may be a request for data or a request to mod- 
ify existing data. Such messages are processed by pro- 
viding the requested data or providing a confirmation 
that the existing data has been modified to the billing 
entity customer service center 104. The billing entity 
customer service center 104 could, for example, be a 
third party telemarketing group that is allowed access to 
billing and overall system data in order to provide feed- 
back to system subscribers. 

EPCS CUSTOMER CARE MESSAGE PROCESSING 

[0107] The EPCS entity 58 will process customercare 
messages from a customer care entity, such as the 
EPCS entity customer service center 106. A customer 
care message may be a request for data or a request to 
modify existing data. Such messages are processed by 
providing the requested data or providing a confirmation 
that the existing data has been modified to the EPCS 
entity customer service center 106. The EPCS entity 
customer service center 106 could, for example, be a 
third party telemarketing group that is allowed access to 
event and overall system data in order to provide feed- 
back to system subscribers. 



[0108] It should be noted that all of the customer care 
entities described above could, if desired, be consoli- 
dated into a centralized customer service center 1 1 0, as 
shown in Figure 9. In such a case, each of the database 

5 entities would process customer care messages to and 
from the centralized customer service center 110 in ?. 
manner similar to that described above. Communica- 
tions between the various database entities and the cen- 
tralized customer service center 110 would be per- 

10 formed over interconnections 112, which may be wire, 
optical fiber, or wireless interconnections. 

MESSAGE FLOW 

15 [0109] Referring to Figures 10-15, there are shown 
flowchart diagrams of data and message flows between 
the various entities within the system 50. These flow- 
chart diagrams assume that the user entity 52 is an 
HTML browser client, the banking entity 54 is the prima- 
ry point of presence for a subscriber to the system 50, 
the billing entity 56 controls bill presentment, and the 
EPCS entity 58 controls bill payment. 
[0110] In Figure 10, a subscriber at the user entity 52 
accesses the web site of the banking entity 54 in step 
200. In return, the banking entity 54 presents a branded 
interface to the user entity 52, including a sign-on re- 
quest prompt in step 202. Figure 16 shows an example 
of such a branded interface 120, wherein the sign-on 
request prompt includes a username field 122 and a 
password field 124. 

[0111] In Figure 11, the user entity 52 submits a sign- 
on request with authentication credentials in steps 204. 
The banking entity 54 messages the EPCS entity 58 
with the authentication credentials of the subscriber and 
the event is logged in step 206. The EPCS entity 58 pro- 
vides a security ticket to the banking entity 54 in step 
208. The banking entity 54 delivers the security ticket to 
the user entity 52 and presents its "home page" to user 
entity 52 in step 210. Figure 17 shows an example of 
such a home page 1 30, which includes a "view bills" icon 
132, a "view checking account" icon 134, and a "view 
savings account" icon 1 36. 

[0112] It should be noted that either the EPCS entity 
58 or the banking entity 54 could perform the authenti- 
cation procedure. In either case the event is logged in 
the event tracking database. 

[0113] In Figure 12, the subscriber selects the "view 
bills" icon 132 in step 212. The banking entity 54 mes- 
sages the EPCS entity 58 with an aggregation data re- 
quest and the event is logged in step 214. The EPCS 
entity 58 presents aggregation data of bill availability to 
user entity 52 in step 216. 

[0114] Figure 18 shows a modified home page 140 
having an EPCS entity frame 142 presenting the bill 
availability data, which includes an "electric bill" icon 
144, a "gas bill" icon 146, a "phone bill" icon 148, a "ca- 
ble bill" icon 150, a "credit card bill" icon 152, and an "all 
bills" icon 154 which allows all bills to be presented si- 
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multaneously, albeit in separate frames. 
[0115] In Figure 13A, the subscriber selects the "gas 
bill" icon 146 and is linked to the billing entity 56. The 
security ticket is transmitted in step 218. The billing en- 
tity 56 messages the EPCS entity 58 to log the "view s 
bill" request event in step 220. The billing entity 56 
presents detailed bill data to the user entity 52 in step 
222. 

[0116] Figure 19 shows another modified home page 
160 having a billing entity frame 162 presenting the de- 
tailed bill data, which includes the subscriber name, sub- 
scriber address, account number, usage, and cost, and 
a "pay bill" icon 164. 

[0117] In Figure 14, the subscriber selects the "pay 
bill" icon 164 and messages the EPCS entity 58 with a 
forward dated pay bill request. The event is logged in 
step 224. The EPCS entity 58 messages the billing en- 
tity 56 with a pay bill request notification along with a bill 
identification number in step 226. 
[0118] In Figure 15, the EPCS posts a debit with the 
banking entity 54, and the event is logged in step 228. 
The EPCS entity 58 then remits a payment to the billing 
entity 56 and the event is logged in step 230. 
[0119] Figure 13B can be substituted for Figure 13A 
in the above-described sequence of flowchart diagrams 
if detailed bill data is provided by the established billing 
aggregator 94 thru the partner message interface 38 of 
the billing entity 56. As shown, the subscriber again se- 
lects the "gas bill" icon 146 and is linked to the billing 
entity 56. The security ticket is transmitted in step 232. 
The billing entity 56 again messages the EPCS entity 
58 to log the "view bill" request event in step 234. How- 
ever, in this case, detailed bill data is available only from 
the established billing aggregator 94, Thus, the billing 
entity 56 accesses the established billing aggregator 94 
through its partner message interface 38 in step 236. In 
response, the established billing aggregator 94 provides 
detailed bill data to the billing entity 56 in step 238. The 
billing entity 56 then presents the detailed bill data to the 
user entity 52 in step 240. 

[0120] It should be noted that, if desired, the estab- 
lished billing aggregator 94 could present the detailed 
bill data directly to the user entity 52. 
[0121] Figure 13C can be substituted for Figure 13A 
in the above-described sequence of flowchart diagrams 
if detailed bill data is provided by the alternative bill pre- 
sentment and payment system 96 thru the partner mes- 
sage interface 38 of the EPCS entity 58. As shown, the 
subscriber selects the "gas bill" icon 146 and is linked 
back to the EPCS entity 58. The security ticket is trans- 
mitted and the event is logged in step 242. 
[0122] In this case, detailed bill data is available only 
from the alternative bill presentment and payment sys- 
tem 96. Thus, the EPCS entity 58 accesses the alterna- 
tive bill presentment and payment system 96 through its 
partner message interface 38 in step 244. In response, 
the alternative bill presentment and payment system 96 
provides detailed bill data to the EPCS entity 58 in step 



246. The EPCS entity 58 then presents the detailed bill 
data to the user entity 52 in step 248. 
[0123] Alternatively, detailed bill data could, if desired, 
be provided by the alternative bill presentment and pay- 
ment system 96 thru the partner message interface 38 
of the billing entity 56 in a manner similar to that as de- 
scribed in Figure 13B. 

[0124] Referring to Figure 20, there is shown a flow- 
chart diagram of data and message flows between the 
centralized customer service center 1 1 0 and the various 
entities within the system 50. A subscriber 1 70 contacts 
the centralized customer service center 110 regarding 
a bill payment in step 250. The centralized customer 
service center 110 accesses the event tracking data- 
base in the EPCS entity 58 to see if a view bill, pay bill, 
remit payment, or debit posting event has been logged 
in step 252. If more detailed information regarding, for 
example, the posting of a debit for a bill is required, the 
centralized customer service center 1 1 0 can access the 
database component 32 associated with the banking 
entity 54, as shown in step 254. Similarly, if more de- 
tailed information regarding, for example, the remitting 
of a payment for a bill is required, the centralized cus- 
tomer service center 1 1 0 can access the database com- 
ponent 32 associated with the billing entity 56, as shown 
in step 256, Although not shown, the EPCS entity 58 
can log all of the above-described accesses performed 
by centralized customer service center 110. 
[0125] As is apparent from the foregoing description, 
the system 50 allows a subscriber to interact directly 
with individual biflers while retaining the benefits of in- 
teracting with a single aggregator, such as a single au- 
thentication and log-in procedure and a common bill 
presentation framework. The system 50 also allows a 
subscriber to interact with a single aggregator while al- 
lowing the billers and banks to retain control of subscrib- 
er-related data and a communication channel with each 
subscriber. 

[0126] The present invention is not to be limited in 
scope by the specific embodiments described herein. 
Indeed, various modifications of the present invention 
in addition to those described herein, will be apparent 
to those of skill in the art from the foregoing description 
and accompanying drawings. Thus, such modifications 
are intended to fall within the scope of the appended 
claims. 



Claims 

1 . A method for accessing data over a network having 
a plurality of network stations, the method compris- 
ing the steps of: 

storing, at a first of the plurality of network sta- 
tions, information that identifies data which is 
available at a second of the plurality of network 
stations, the second network station being dif- 
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ferent than the first network station; 
generating, at the first network station, a signal 
representing both the information that identifies 
the available data and linking information to the 
second network station; and 

+;^p<>**"jiHtr»ri tho ei<-inol trs o thirrl r»f the* rtlliralttw 

of network stations, the third network station 
being different than the first and the second net- 
work stations; 

wherein the transmitted linking information is 
operable at the third network station to estab- 
lish a network link over which the identified 
available data is transmittable from the second 
network station to the third network station. 

The method according to claim 1 , further compris- 
ing the steps of: 

receiving a request for the information that 
identifies the available data, wherein the signal 
is generated responsive to the responsive to 
the request; and 
logging the request. 

The method according to claim 1 , further compris- 
ing the steps of: 

operating on the transmitted linking information 
at the third network station to establish the net- 
work link; 

receiving, at the second network station, a re- 
quest for the identified available data from the 
third network station via the established net- 
work link; 

receiving, at the first network station, a notifica- 
tion of the receipt of the request for the identi- 
fied available data from the second network 
station; and 
logging the notification. 

The method according to claim 1 , further compris- 
ing the steps of: 

operating on the transmitted linking information 
at the third network station to establish the net- 
work link; 

transmitting, from the second network station, 
the identified available data to the third network 
station via the established network link; 
receiving, at the first network station, a notifica- 
tion that the identified available data was trans- 
mitted from the second network station to the 
third network station; and 
logging the notification. 

The method according to claim 1 , wherein the iden- 
tified available data is identified available first data, 
wherein the linking information is first linking tnfor- 
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mation, wherein the network link is a first network 
link, further comprising the steps of: 

storing, at the first network station, further infor- 
mation that identifies second data which is 
available at a fourth of the plurality of network 
stations, the fourth network station being differ- 
ent than the first, the second, and the third sta- 
tions; 

wherein the generated signal further repre- 
sents both the further information that identifies 
the available second data and second linking 
information to the fourth network station; 
wherein the transmitted second linking informa- 
tion is operable at the third network station to 
establish a second network link over which the 
identified available second data is transmitta- 
ble from the fourth network station to the third 
network station. 

The method according to claim 5, further compris- 
ing the step of: 

operating on the transmitted first linking infor- 
mation at the third network station to establish 
the first network link, and on the transmitted 
second linking information at the third network 
station to establish the second network link; 
receiving, at the second network station, a re- 
quest for the identified available first data from 
the third network station viathe established first 
network link and, at the fourth network station, 
a request for the identified available second da- 
ta from the third network station via the estab- 
lished second network link; 
receiving, at the first network station, a first no- 
tification of the receipt of the request for the 
identified available first data from the second 
network station, and a second notification of the 
receipt of the request for the identified available 
second data from the fourth network station; 
and 

logging the first and the second notifications. 

The method according to claim 5, further compris- 
ing the steps of: 

operating on the transmitted first linking infor- 
mation at the third network station to establish 
the first network link, and on the transmitted 
second linking information at the third network 
station to establish the second network link; 
transmitting, from the second network station, 
the identified available first data to the third net- 
work station via the established first network 
link and, from the fourth network station, the 
identified available second data to the third net- 
work station via the established second net- 
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work link; 

receiving, at the first network station, a first no- 
tification that the identified available first data 
was transmitted from the second network sta- 
tion to the third network station, and a second 
notification that the identified available second 
data was transmitted from the fourth network 
station to the third network station; and 
logging the first notification and the second no- 
tification. 

8. The method according to claim 5, wherein the re- 
quest includes an identification of a user and further 
comprising the steps of: 

receiving a request from a user for the informa- 
tion that identifies the available first data and 
the available second data, wherein the signal 
is generated responsive to the responsive to 
the request; and 
authenticating the user; 
wherein the signal is generated after the user 
is authenticated. 

9. A method for electronically presenting and paying 
bills in a network having a plurality of network sta- 
tions, the method comprising the steps of: 

storing, at a first of the plurality of network sta- 
tions, information identifying a bill which is 
available at a second of the plurality of network 
stations, the second network station being dif- 
ferent than the first network station; 
receiving, from a third of the plurality of network 
stations, a request for the information identify- 
ing the available bill, the third network station 
being different than the first and the second net- 
work stations; 

authenticating the request from the third net- 
work station; 

generating, at the first network station, a signal 
representing the information identifying the 
available bill and linking information to the sec- 
ond network station, the linking information be- 
ing operative at the third network station to es- 
tablish a network link over which the identified 
available bill is transmittable from the second 
network station to the third network station; 
transmitting the signal to the third network sta- 
tion; 

receiving, at the first network station, a notifica- 
tion that the identified available bill was trans- 
mitted from the second network station to the 
third network station; and 
logging at least one of the request receipt and 
the notification. 

1 0. An system for accessing data over a network having 



a plurality of network stations, comprising: 

a storage device configured to store, at a first 
of the plurality of network stations, information 
5 identifying data which is available at a second 

of the plurality of network stations, the second 
network station being different than the first net- 
work station; and 

a processor configured to generate, at the first 
10 network station, a signal representing the infor- 

mation identifying the available data and linking 
information to the second network station, and 
to transmit the signal to a third of the plurality 
of network stations, the third network station 
15 being different than the first and the second net- 

work stations; 

wherein the transmitted linking information is 
operable at the third network station to estab- 
lish a network link over which to communicate 
20 a request from the third network station to the 

second network station for the identified avail- 
able data. 

1 1 . The system according to claim 1 0, wherein: 

25 

the processor is further configured to receive a 
request for the data from the third network sta- 
tion and to log the request; and 
the signal is generated responsive to the re- 
30 ceipt of the request. 

12. The system according to claim 10, wherein: 

the processor is further configured to receive 
a notification that the identified available data was 
35 transmitted from the second network station to the 
third network station and to log the notification. 

13. The system according to claim 10, wherein: 

40 the identified available data is identified availa- 

ble first data; 

the linking information is first linking informa- 
tion; 

the network link is a first network link; 
45 the storage device is further configured to store 

further information identifying second data 
which is available at a fourth of the plurality of 
network stations, the fourth network station be- 
ing different than the first, the second, and the 
50 third network stations; 

the processor is further configured to generate 
the to additionally represent the further infor- 
mation identifying the available second data 
and second linking information to the fourth net- 
55 workstation; 

wherein the transmitted second linking informa- 
tion is operable at the third network station to 
establish a second network link over which to 
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communicate a request from the third network 
station to the fourth network station for the iden- 
tified available second data. 

14. The system according to claim 13, wherein: s 

the processor is further configured to receive 
a first notification that the identified available first 
data was transmitted from the second network sta- 
tion to the third network station and a second noti- 
fication that the identified available second data 10 
was transmitted from the fourth network station to 
the third network station, and to log the first and the 
second notifications. 

15. The system according to claim 1 3, wherein: 1$ 

wherein the processor is further configured to 
receive a first notification of a receipt of a request 
for the identified available first data from the second 
network station, and a second notification of a re- 
ceipt of a request for the identified available second 20 
data from the fourth network station, and to log the 
first and the second notifications. 

16. An system for electronically presenting and paying 
bills in a network having a plurality of network sta- 25 
tions, comprising: 

a storage device configured to store, at a first 
of the plurality of network stations, information 
identifying a bill which is available at a second 30 
of the plurality of network stations, the second 
network station being different than the first net- 
work station; and 

a processor configured to receive, from a third 
of the plurality of network stations, a request for 35 
the information identifying the available bill, the 
third network station being different than the 
first and the second network stations, to au- 
thenticate the request from the third network 
station, to generate a signal representing the *o 
information identifying the available bill and 
linking information to the second network sta- 
tion, to transmit the signal to the third network 
station, to receive a notification that the identi- 
fied available bill was transmitted from the sec- 45 
ond network station to the third network station, 
and to log at least one of the request receipt 
and the notification. 
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